Field service — the on-site execution bounded context
The field engineer's on-site execution context and the source of truth for what happens at the customer site: the Visit lifecycle (corrective from a ticket, preventive from a maintenance plan), runbook checklist tasks, parts used, photo/document evidence, the customer sign-off that seals a visit, and the per-device maintenance plans that drive preventive scheduling. A core subdomain — on-site service is how RiverSync delivers the agreement.
1Ownership & boundaries
Field owns the Visit and everything captured against it. Visit is the bridge to records it does not own — it references a Support ServiceTicket (corrective), a Devices Device, a Structure OrganizationSite (the scope-gated support fields, read for the assignment only) and an Identity engineer account. The service is offline-first: tasks, parts, evidence and sign-off are created on the device with client ids and synced idempotently — Field is the only writer of those records (SVC-14).
Reads from: Support (ServiceTicket) · Devices (registry) · Agreement (SLA tier, partner scope) · Structure (site support-visit info) · Identity (engineer accounts). RiverSync-only — the Field BFF (field.riversync.com) is membership-gated to the engineer role (AUTH-2, AUTH-5).
2Ubiquitous language
The words this context uses — the same in code, conversation and spec.
3Aggregates & invariants
The consistency boundaries — one root each, guarding its invariants in a single transaction; cross-aggregate ties are by identity.
4Context relationships
How this context meets its neighbours. Field is in a partnership with Support — a corrective ticket dispatches a visit; a signed-off visit lets Support resolve it.
5Physical view — the service API
The deployment mapping: this context becomes the Field service. Paths relative to api.riversync.com/v1; the offline client batches its queue to POST /field/sync. Access notation per the master.